home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 514 < prev    next >
Internet Message Format  |  1996-08-06  |  3KB
  1. Path: sdrc.com!thor!scjones
  2. From: larry.jones@sdrc.com (Larry Jones)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Bit-field sizes
  5. Date: 6 Mar 1996 17:01:48 GMT
  6. Organization: SDRC Engineering Services
  7. Distribution: world
  8. Message-ID: <4hkgds$bbh@info1.sdrc.com>
  9. References: <nzRPxQ9ytZZA084yn@csn.net>
  10. NNTP-Posting-Host: thor.sdrc.com
  11. Originator: scjones@thor
  12.  
  13. In article <nzRPxQ9ytZZA084yn@csn.net>, thads@csn.net (Thad Smith) writes:
  14. > Can the size of a bit-field, measured in bits, exceed the size of an
  15. > int?  The description of bit-fields describes it as an integral
  16. > type with a (programmer-)specified number of bits, not specifically
  17. > constrained in size.  ANSI Classic section 3.2.1.1 says, however, that
  18. > bit-fields are promoted to either int or unsigned int.  This would
  19. > seem to prohibit promoting a large bit-field to a long.  If so, why
  20. > was this constraint imposed?
  21.  
  22. No.  ANSI Classic 3.5.2.1:
  23.  
  24.     The expression that specifies the width of a bit-field shall be
  25.     an integral constant expression that nas nonnegative value that
  26.     shall not exceed the number of bits in an ordinary object of
  27.     compatible type.
  28.  
  29. The constraint is historical, probably because extracting a bit-field
  30. that is longer than a word is sufficiently complicated as to be contrary
  31. to the ``spirit of C''.
  32.  
  33. > Secondly, is the storage unit within which bit-fields are allocated
  34. > constrained to be a single size or can it vary, depending on the size
  35. > of the bit fields?  I see nothing in the standard prohibiting
  36. > different size storage units for bit-fields.  Also bit-fields are
  37. > explicitly allowed to span multiple storage units, at least if the
  38. > bit-field is not the first in a structure (the use of the word "may"
  39. > makes the requirement for the first bit-field ambiguous with regard to
  40. > storage in a single unit).
  41.  
  42. It can vary (my emphasis):
  43.  
  44.     An implementation may allocate *any* addressable storage unit
  45.     large enough to hold a bit-field.
  46.  
  47. Thus, an implementation is free to allocate a char for a 1 bit field and
  48. an int for a 14 bit field.
  49.  
  50. > If different size storage units are allowed or any bit-field is
  51. > allowed to span multiple units, the size of a struct containing
  52. > bit-fields might be 1 byte, while bit-fields could be allocated up to
  53. > the size (in bits) of ints, possibly four bytes in a particular
  54. > implementation, by choosing larger storage units for larger
  55. > bit-fields.
  56.  
  57. Correct.
  58.  
  59. > Is anyone aware of an implementation using bit-field storage units
  60. > smaller than int?
  61.  
  62. Lots of them.
  63. ----
  64. Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
  65. larry.jones@sdrc.com
  66. In my opinion, we don't devote nearly enough scientific research
  67. to finding a cure for jerks. -- Calvin
  68.